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REMARKS 



Claims 1-12 are pending in the Application. The term "participants'" has 
been changed to "participant's" to correct an informality at Claim 3, line 2, and at 
Claim 11, line 2. Claim 7 has been amended by: (i) changing "executing" to 
"using a workflow engine that executes" at line 3; (ii) deleting the phrase "storing 
user context information" at line 5; (iii) adding the phrase "using a context service 
to provide context-aware applications with user context information" at lines 6-7; 
(iv) adding the phrase "from the workflow engine to an interaction controller" at 
lines 8-9; and (v) changing "context information" to "context service" at 
lines 11-12. These changes are done to make Claim 7 consistent with Claim 1, 
lines 3, 4-5, 6, and 8-9, and are supported by Figure 1 and by the Specification 
at page 7, lines 8-27. In addition, Claim 1 has been amended at lines 6-7 to clarify 
that the interaction controller "acts as a proxy to represent one or more human 
participants in a workflow," and a similar amendment has been made to Claim 7, 
lines 9-10. Support for these amendments may be found in the Specification at 
page 5, line 14. Finally, Claim 1 has been amended at lines 18-19 to clarify that 
the modality adapter is "to receive a task from the interaction controller and 
deliver the task to said partner instance in a modality-specific format," and a 
similar amendment has been made to Claim 7, lines 16-17. Support for these 
amendments may be found in the Specification at page 5, lines 27-28. No new 
matter is added. 

Claims 1-12 stand rejected under 35 U.S.C. § 102(b) as being anticipated 
by U.S. Patent No. 6,334,146 to Parasnis et al. Applicants traverse as discussed 
below. 
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The Claimed Invention 

The term "workflow" refers to the automatic routing of documents to users 
responsible for working on them. (See, e.g., the TechEncyclopedia at 
TechWeb.com) As discussed in the Specification, a workflow management 
system includes a workflow engine that carries out automatic scheduling and 
activation of component tasks according to defined business process, while also 
providing formalisms through which business processes are defined. Prior art 
workflow systems are based on the desktop computing paradigm and employ a 
workspace metaphor to present tasks that are to be claimed and performed by 
human participants. Such tasks differ from tasks that are performed by software 
agents and are referred to as staff activities. (Specification, page 2, lines 16-23) 

Prior art approaches have a number of disadvantages, including: (i) users 
are constrained to the desktop computing environment and do not have access to 
business processes when they are away from their desktop; (ii) a user is burdened 
to periodically inspect his or her workspace to check out pending staff activities; 
and (iii) prior art approaches allow for indirect and asynchronous communication, 
but do not allow for direct and synchronous exchanges among human participants, 
which is very common in business environments. (Specification, page 3, 
lines 7-15) 

Addressing these disadvantages, the claimed invention provides a system 
for pervasive enablement of business processes in which a workflow engine 
executing a business process model has access to a context service to allow 
context-aware applications to obtain user context information. An interaction 
controller , acting as a proxy for human participants in a workflow, determines an 
appropriate collaboration modality for a human participant, and one or more 
modality adapters encapsulate details of communicating with a specific 
collaboration modality to receive a task from the interaction controller and deliver 
the task in a modality- specific format. (Specification, page 5) 
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As shown in Figure 1, an interaction controller 1040 interfaces with a 
workflow engine 1030 and a context service 1050. The workflow engine 1030 
executes the business process based on business process models 1010 and engages 
human partners through software agents 1 100 and invoking software 
applications 1020 by dispatching various tasks to them. Acting as a proxy for all 
human participants in a workflow, the interaction controller 1040 receives 
specification of individual staff activities from the workflow engine 1030 and 
forwards the engine responses from human partners back to the workflow 
engine 1030. A staff activity specification contains information about the human 
partner instance intended to carry out the activity and the relevant messages. Upon 
receiving a staff activity specification, the interaction controller 1040 obtains 
context information of the partner instance from the context service 1050 and 
determines an appropriate collaboration modality for the partner instance. It uses 
an address book 1090 to look up the modality-specific address (e.g., telephone 
number, email address, instant messaging identifier) based on the user name. It 
then establishes communication with the corresponding modality adapters (e.g., 
instant messaging adapter 1060, short messaging service adapter 1070, or email 
adapter 1080) and supplies it with all the information regarding the staff activity. 
(Specification, page 7, lines 8-27) 

Rejection of Claims 1-12 Under 35 U.S.C. § 102(b) 
Claims 1-12 stand rejected under 35 U.S.C. § 102(b) as being anticipated 
by Parasnis et al. Applicants traverse on the basis that Parasnis et al. do not 
describe or anticipate Claims 1-12. Parasnis et al. describe a prior art system 
which does not anticipate features of independent Claims 1 and 7, from which the 
other claims depend. More particularly, Parasnis et al. do not anticipate use of a 
context service (Claim 1, lines 4, 12; Claim 7, lines 6, 1 1-12), an interaction 
controller (Claim 1, line 6; Claim 7, line 9), or a modality adapter (Claim 1, 
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line 17; Claim 7, lines 14, 18) as required by Claims 1 and 7. 

Requirement of a "Context Service " 
Claims 1 and 7 require a context service , which enables the workflow 
engine to obtain user context information. (Claim 1, lines 4-5; Claim 7, lines 6-7) 
The context service of the claimed invention "gathers and distributes dynamic 
context information of the human participants," thus enabling the interaction 
controller "to select the access mechanism that is most convenient for a particular 
human participant." (Specification, page 5, line 22-23, 24-25) As discussed 
above, Claims 1 and 7 use this feature to solve problems not addressed in the prior 
art. The Examiner has incorrectly understood "context" as referring to the role of 
a human participant in a workflow, (see Office Action at 2, discussing Claim 1 
and citing Parasnis et al., column 14, lines 32-50) The term "context service" is 
used in the Specification as follows: 

The Context Service 1050 provides both dynamic user context 
information and static user preferences. Dynamic context 
information currently available from the Context Service includes 
IM online status, activities and contact means derived from 
calendar entries, desktop activities, as well as user location 
reported from a variety of sources such as cellular providers, 
wireless Loal Area networks (LANs), Global positioning Satellite 
(GPS) devices, and handheld Personal Digital Assistants (PDAs) 
such as Research in Motion Ltd. BlackBerry™ devices. 
(Specification, page 8, line 22 - page 9, line 1) Because a "context service" is 
required by Claims 1 and 7 (Claims 1, line 4, 13; Claim 7, lines 6, 11-12), the 
Examiner's misunderstanding of this term fundamentally undermines the basis of 
the rejection these claims. 
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Requirement of an "Interaction Controller" 
To overcome disadvantages of the prior art, Claims 1 and 7 also require an 
interaction controller which " acts as a proxy to represent one or more human 
participants in a workflow ." (Claim 1, lines 6-7; Claim 7, lines 9-10) Because 
the interaction controller acts as a proxy for human participants in a workflow, the 
functionality of the interaction controller is applied every time a document is to be 
routed to a human participant in the workflow. The interaction controller "obtains 
context information of a partner instance from the context service to determine an 
appropriate collaboration modality for the partner instance." (Claim 1, lines 11-13, 
emphasis added; see also Claim 7, lines 11-13) This results in the workflow 
being adapted on the fly, while it is in progress, to use the most appropriate 
modality for contacting each human participant in the workflow. Parasnis et al. 
do not teach or disclose this feature. 

The Examiner incorrectly found these and other feature of Claims 1 and 7 
to be anticipated by Parasnis et al. In making this incorrect finding, the Examiner 
relies in part on the following passage from Parasnis et al.: 

FIG. 10 is a diagram of one embodiment of designing an 
inter-enterprise workflow that includes parameterization over 
groups. As shown, the workflow can begin with a listening activity 
70 that waits for some event. Activity 70 can be linked to parallel 
activities 71 that links to a sub-workflow 72 and to a heterocast 
split 73. Sub-workflow, itself, can include a workflow definition. 
With respect to HETEROCASTING, the workflow after heterocast 
split 73 then becomes parameterized. Thus, in the example of FIG. 
10, activity 74 is a parameterized activity. After activity 74, a 
heterocast join 75 receives flow from activity 74. Sub-workflow 
72 and heterocast join 75 are linked to a synchronous or 
asynchronous join 76 which, in turn, links to an integrated event 77 
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(e.g., multicasting). A workflow like that of FIG. 10 can be 
designed using the present global collaboration designer and can 
allow full representation of workflow for inter-enterprise decision 
support. This workflow can then be instantiated and implemented 
through the present global collaboration manager. 

FIG. 1 1 is a diagram of one embodiment of managing 
change be modifying a design of a workflow. As shown, an initial 
workflow design can have an event 70 linked to a parallel activity 
split 71. Between activity split 71 and a join 76, there can be, for 
example, two activities 78. This work flow, once designed, can be 
instantiated and implemented using the global collaboration 
manager. If a change needs to be made to the workflow, the global 
collaboration designer greatly alleviates the trouble of making the 
change. For example, a new activity 79 can be added between split 
7 1 and join 76. The workflow can then be centrally reinstantiated 
and implemented. 

(Parasnis et al., column 13, lines 54-67, cited in the Office Action at 3) Neither 
the cited passage from Parasnis et al., nor the drawings discussed in that passage, 
describe the feature of the claimed invention which the Examiner finds to be 
anticipated by the cited passage. Parasnis et al. do not anticipate using an 
interaction controller, acting as a proxy to represent human participants in a 
workflow, to obtain context information of a partner instance from a context 
service to determine an appropriate collaboration modality for the partner 
instance. 
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Requirement of a "Modality Adapter " 
Claims 1 and 7 further require the use of modality adapters that 
encapsulate details of communicating with specific collaboration modalities to 
receive a task from the interaction controller and deliver the task to a partner 
instance in a modality-specific format. (Claim 1, lines 17-19; Claim 7, 
lines 14-17) The Examiner incorrectly concluded that Parasnis et al. anticipate 
one or more modality adapters (Office Action at 3), even though the passage of 
the disclosure of Parasnis et al. relied on for this purpose does not include any 
discussion of employing multiple communications modalities: 

The global collaboration manager can support a 
component-based integration model. The component-based 
integration model allows flexibility in structuring the integration. 
There can be two types of components: primitive components and 
compound components. Primitive components can include 
accessors 80, transformers 82 and transfer objects 84. Compound 
components include adaptors and flows 86. Compound 
components are built in terms of primitive components. In this 
scheme, accessors 80 are used to access an external source such as 
SCP (SUPPLY CHAIN PLANNER), SAP, a relational database, 
web servers, email, message buses etc. Accessors 80 can be used to 
read, write or listen to sources and destinations of data. 
Transformers 82 can be used to transform data from one form to 
another form. Transfer Objects 84 are objects that can be passed 
from activity to activity or from enterprise to enterprise. Transfer 
objects 84 can be optionally convertible to EDI, XML, CORBA 
structures etc. Accessors 80 and Transformers 82 can be strung 
together to form flows. An entire flow can be executed in a single 
activity as shown in FIG. 13. 
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(Parasnis et al, column 15, lines 1-29, cited in the Office Action at 3) Thus, 
while Parasnis et al. make reference to "adaptors" (Parasnis et al., column 15, 
line 16), those are not the modality adapters of the claimed invention. Parasnis et 
al. do not anticipate the use of modality adapters as in Claims 1 and 7. 

Dependent Claims 

With regard to Claims 2, 3, and 4, the Examiner has again misunderstood 
"context" as discussed in connection with Claim 1, above. (Office Action at 3, 
discussing Claim 2 and citing Parasnis et al., column 14, lines 32-50) Parasnis et 
al. do not use "context" in the same sense as the claimed invention. 

With regard to Claim 4, the Examiner is incorrect in finding that Parasnis 
et al. anticipate the requirement "wherein the context service supports both 
synchronous query and asynchronous callback context functions." (Claim 4, 
lines 1-2, emphasis added) Where Parasnis et al. refer to synchronous or 
asynchronous communications with native applications as part of the workflow 
activities (Parasnis et al., column 5, lines 11-16, cited in the Office Action at 4), 
Claim 4 refers to obtaining context information in a synchronous or asynchronous 
manner from the context service in preparation for a workflow activity. This is 
not anticipated by Parasnis et al. 

With regard to Claims 5 and 6, the Examiner is incorrect in reading 
Parasnis et al. as anticipating the use of multiple communications modalities, as 
discussed above. 

The Examiner does not specifically discuss Claims 8-12, except to 
incorporate the rejection of Claims 2-6 by reference. For that reason, the traversal 
of Claims 2-6 is extended by reference to Claims 8-12. 
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Conclusion 



In view of the foregoing, it is respectfully requested that the application be 
reconsidered, that Claims 1-12 be allowed, and that the application be passed to 
issue. 

Should the Examiner find the application to be other than in condition for 
allowance, the Examiner is requested to contact the undersigned at the local 
telephone number listed below to discuss any other changes deemed necessary in 
a telephonic or personal interview. 

A provisional petition is hereby made for any extension of time necessary 
for the continued pendency during the life of this application. Please charge any 
fees for such provisional petition and any deficiencies in fees and credit any 
overpayment of fees to Deposit Account 50-0510 (IBM-Yorktown). 
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